Verifica TDP

Architetture Software

Creazione di un modello software a livelli separati per i seguenti benefici:

· Individuazione degli errori semplificata e mirata;

· Codice ordinato;

· Individuazione del codice da modificare più semplice.

Multi Tier/Layer è il termine che definisce un’architettura software sviluppata su più livelli. In questi modelli l’applicativo è sviluppato su più livelli indipendenti che possono comunicare fra loro e dividendosi i compiti.

Ogni livello può comunicare solamente con i livelli immediatamente vicini a lui, ogni livello deve essere indipendente dagl’altri per quanto riguarda implementazione e architettura interna.

L’indipendenza logica è l’indipendenza per la quale è possibile modificare un livello senza intaccare gli altri

L’indipendenza fisica è tale se è possibile modificare la posizione o tipologia dei file/DB senza avere ripercussioni sulla struttura degli altri livelli.

Layer(logico) riguarda una separazione logica spesso dentro la stessa applicazione.

Tier(fisico) riguarda una separazione fisica degli applicativi, se sono ben progettati gli applicativi sono indipendenti fra loro.

I software si possono suddividere in livelli, storicamente i livelli sono 3:

· Presentazione: Il software più esterno che di solito si occupa di fare vedere graficamente i dati agli utenti (GUI)

· Logico: quello che esegue le elaborazioni dati che il livello Presentazione gli invia da parte dell’utente, e restituisce i risultati (Classi)

· Data Access: quello che gestisce e manipola i dati su memoria di massa.

Oltre a questi abbiamo i Dati veri e DBMS – Database

ANNI ’80 – UNICO LIVELLO

Caratteristiche: Tutti i livelli uniti, sullo stesso software e mancanza di indipendenza fisica e logica

Nome: Stand Alone

Problemi:

· Scalabilità: se la mole di dati e/o computazioni cresce spesso è necessario riscrivere il software in ogni sua parte

· Portabilità: Dipende completamente dalla macchina e dal SO

· Manutenzione: Spesso è difficile perché è difficile individuare la sezione del software che esegue quel determinato compito

ANNI ’80 – ’90 I LIVELLI SI SEPARANO

Si è necessitato di una separazione dei livello rimanendo comunque in un unico tier.

L’indipendenza logica non è mai assoluta e per questo si tende almeno a tener separati i livelli di presentazione da quello delle classi anche se la modifica di un algoritmo rende spesso necessaria la modifica di interfacce o altre classi

ANNI ’90 – STRUTTURA 2 TIER

Nome: Architettura Client – Server

Caratteristiche: Viene implementata l’indipendenza fisica fra il livello fisico (Server) e quello di presentazione (Client). I livelli Business Logic e Presentazione sono ancora strettamente legati.

Le applicazioni Client – Server possono usare protocolli o applicativi realizzati ad hoc per comunicare o protocolli standard

Applicazioni Web usano applicativi preesistenti (Browser) e Server (ISS, Apache)

ANNI 2000 – APPLICAZIONI A 3 TIER

Nasce per Web

Utilizzato anche dai Client-Server

Il livello di presentazione può comunicare solo con il Logico e non Con il Data Access

Tipicamente: Web server e DBMS sono sulla stessa macchina Server

Il livello presentazione sta sul client e di solito progettato con linguaggi standard

MULTI – TIER

Possibili moduli aggiuntivi potrebbero essere: Networking, Security, Data Access

Web Service SOAP e REST

Sono i due modi di approcciare il mondo dei Servizi Web, anche se hanno lo stesso fine.

I Soap Web Service mettono in risalto il concetto di Servizio, mentre i Rest mettono in risalto il concetto di risorsa

SOA -> Service Oriented Service(SOAP)

ROA -> Resource Oriented Service(REST)

SOAP:

· Non sfrutta a pieno il protocollo http, ma lo usa per il trasporto

· Nasce come adattabilità al web a tecnologie di interoperabilità esistenti indipendentemente dal web

· Prevedono l’uso di WSDL per descrivere l’interfaccia di un servizio

· Definisce uno standard indipendente dal Web e dall’infrastruttura può essere usata anche su protocolli diversi dal http.

REST:

· Sfrutta appieno http come protocollo di livello applicativo, e ne utilizza completamente le funzionalità (sicurezza, indirizzamento)

· Conserva tutte le caratteristiche del Web evidenziandone la predisposizione ad essere una piattaforma per applicazioni distribuite

· Non prevede esplicitamente nessuna modalità di interazione con le risorse, sono dentro il protocollo http

· REST usa il Web ad architettura per la programmazione distribuita, non aggiunge sovrastrutture

In un contesto RESTful attraverso il CRUD (Create, Read, Update, Delete) per interagire con le risorse e i metodi http.

La Service Oriented Architecture (SOA) è un’architettura multi strato per costruire servizi sul web o su rete basata sull’architettura Client – Server.

SOA utilizza una logica orientata ai servizi → il sistema software è organizzato in sottoprogrammi (indipendenti fisicamente) detti servizi richiamabili dai programmi client all’occorrenza.

I servizi implementano l’indipendenza fisica di una funzionalità così come le funzioni o le classi (se ben progettate) ne implementano l’indipendenza logica.

SOA è una architettura “loosely – coupled” (debolmente accoppiata) → i servizi girano su piattaforme hardware e software potenzialmente diverse tra loro e generalmente diverse da quelle su cui girano i client: Oltre all’indipendenza logica implementano l’indipendenza fisica.

I client richiamano i servizi attraverso interfacce pubbliche, i servizi funzionano anche se re implementati, aggiornati o spostati senza dover intervenire sul client: finché non se ne modifica l’interfaccia.

Definizione del W3C (World Wide Web Consortium) → un Web Service (servizio web), è un “sistema software progettato per supportare l'interoperabilità tra diversi elaboratori su di una medesima rete ovvero in un contesto distribuito”.

SOAP -> XML -> HTTP -> CLIENT

PROTOCOLLI DI COMUNICAZIONE:

HTTP -> Hypertext Transfert Protocol

SOAP -> Simple Object Access Protocol

WSDL -> Web Service Description Language

UDDI -> Universal Description Discovery and Integration: Catalogazione e scoperta dei servizi.

PROTOCOLLO SOAP:

SOAP è il protocollo su cui si basano i servizi Web, I messaggi Soap sono scritti in linguaggio XML.

L'uso del protocollo è adeguato al paradigma della programmazione orientata agli oggetti.

Il framework definito da SOAP è composto dai seguenti elementi:

· Initial SOAP sender - è il nodo che genera il messaggio;

· SOAP sender - è il componente incaricato di spedire i messaggi SOAP;

· SOAP intermediary - è il componente che si occupa di processare l'header del messaggio SOAP, girandolo al corretto receiver;

· SOAP receiver - è il componente incaricato di ricevere i messaggi SOAP;

· Ultimate SOAP receiver - è il nodo che riceve il messaggio, ovvero il destinatario

WSDL:

Mediante WSDL può essere infatti descritta (in linguaggio XML) l'interfaccia pubblica di un Web Service che indica come interagire con un determinato servizio

In particolare contiene informazioni su:

· Cosa può essere utilizzato

· Come utilizzarlo: il protocollo di comunicazione da utilizzare per accedere al servizio

· Dove utilizzare il servizio

Svantaggi del Web Service:

-Performance: utilizzando XML richiede l’inserimento di dati supplementari indispensabili. Ciò li rende poco adatti a flussi di dati intensi

-HTTP: Bisogna integrare nel codice un gestore di richieste web oppure averne uno esterno.